Method and system for managing data and enabling payment transactions between multiple entities

ABSTRACT

A system for conducting payment transaction includes a network-enabled server that communicates with one or more user devices, other network-enabled server computers, and a payment processing network server computer. The network-enabled server facilitates transactions between one or more merchants and users by a managing data flow and interactions between the merchants and the users, providing storage area for storing of all transaction related documents, and providing seamless integration with a payment processing network for payment processing.

CROSS REFERENCES TO RELATED APPLICATIONS

This application claims priority under 35 USC §119(e) to U.S.Provisional Patent Application No. 61/444,276, filed on Feb. 18, 2011,the disclosure of which is incorporated by reference herein in itsentirety for all purposes.

BACKGROUND

In a traditional payment transaction scenario, a user uses a paymentdevice at an access device to pay for a product or service. The paymentdevice information is sent to a payment processing network, whichcommunicates with an issuer of the payment device to authorize thetransaction. The issuer merely checks if the user has enoughbalance/credit left in the account to cover the amount of transaction.

Thus, in the conventional method there is no validation of thetransaction itself. For example, the issuer cannot request additionaldocumentation from either the merchant or the user to verify whether theservice/product that is subject of the transaction is actually requiredand/or provided to the user. In other words, nothing is done to checkwhether the transaction is genuine, proper, or actually initiated by thepayment device holder. In the conventional system, if the user hasenough balance/credit in his account and the required transactiondetails are provided by the merchant, the transaction is processedwithout additional verification. The problem is especially acute whenthere are more than two entities involved in a transaction where theentity paying for the product/service is not the entity that actuallyreceives the product/service.

Currently, the existing payment processing systems are not equipped tohandle the extra traffic that may be generated by theinformation/documentation related to each payment transaction thatinvolves multiple entities. Thus, there is a need for a newinfrastructure that can handle the increased traffic generated becauseof the extra validation processes and thereafter process payment oncethe transaction is validated.

SUMMARY

Embodiments of the present invention are generally related to processingpayment transactions. In particular, certain embodiments of the presentinvention provide a system that enables end-user devices to interactdirectly with payment processing systems without having to go throughanother entity. Other embodiments of the present invention provide amethod for performing payment transactions with added security andvalidation. The system provides a mechanism for managing alltransactions associated with getting paid for performing a service orgetting paid for selling a product. The system and method disclosedherein minimize the delay between performance of a service and gettingpaid for the performed service and/or selling a product and getting paidfor selling a product.

Some embodiments of the present invention provide a system forprocessing transactions. The system comprises a payment processingnetwork server computer configured to communicate with an issuer toprocess payment requests and a network-enabled server computerconfigured to communicate with one or more external systems. Thenetwork-enabled server computer is further configured to receive apayment request from a merchant computer for authorizing payment for atransaction, request additional information associated with thetransaction from the merchant computer and send a validation request toa user device to validate the payment request. The network-enabledserver computer further receives a response to the validation requestand alias information about the user. network-enabled server computerthen determines payment account information based on the alias. Thenetwork-enabled server computer communicates the payment accountinformation to the payment processing network server computer.

In some embodiments, the network-enabled server computer may alsoreceive information from the payment processing network server computerindicating successful processing of the payment transaction andcommunicate the information to the merchant computer and/or the userdevice. In some embodiments, the network-enabled server computercommunicates with the user device and the merchant computer using WSDLmessaging techniques, RESTful computing techniques, and/or JSON.

Some embodiments of the present invention provide a network-enabledserver computer. The network-enabled server computer includes an aliasdatabase comprising information about one or more aliases, an aliashierarchy database comprising association information between an aliasand one or more objects associated with the alias, an applicationinterface configured to communicate with one or more external devices,and a data storage configured to store data. In some embodiments, theone or more aliases comprise identifiers associated with a plurality ofentities, wherein an entity includes an individual or a company. In someembodiments, the alias database includes payment account informationassociated with an alias. In some embodiments, the one or more objectsinclude mobile communication devices, televisions, and gaming consoles.The application interface may be configured to communicate with the oneor more external devices using WSDL and/or JSON messaging techniques.

Some embodiments of the present inventions provide a method forprocessing a payment transaction. The method includes receiving a firstmessage from a merchant server computer requesting authorization for atransaction, sending a second message to the merchant server computerrequesting additional information related to the transaction, andreceiving a third message from the merchant server computer includingthe requested information. The method further includes sending a fourthmessage to a user device requesting a user to validate the transaction,receiving a fifth message from the user device including validationinformation, and receiving a sixth message from the user deviceincluding payment account information. Thereafter, the method furtherincludes sending a seventh message to a payment processing networkserver computer including the payment account information andtransaction information, receiving an eight message from the paymentprocessing network server computer including results of the paymenttransaction processing, and sending a ninth message to the merchantserver computer including the results of the payment transactionprocessing.

In some embodiments, the additional information related to thetransaction may include documents, images, audio, video, or graphics. Insome embodiments, one or more of the first message, the second message,the third message, the fourth message, the fifth message, the sixthmessage, and the ninth message are sent using WSDL techniques. In someembodiments, one or more of the first message, the second message, thethird message, the fourth message, the fifth message, the sixth message,and the ninth message are sent using RESTful computing techniques. Inother embodiments, one or more of the first message, the second message,the third message, the fourth message, the fifth message, the sixthmessage, and the ninth message are created using JSON. In someembodiments, the first message includes alias information of the user.In an embodiment, prior to sending the fourth message, the servercomputer may consult an alias database to determine the user deviceassociated with the alias. In some embodiments, the payment accountinformation is stored in the server computer.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow diagram of a traditional payment processing process.

FIG. 2 is a functional block diagram of a system according to anembodiment of the present invention.

FIG. 2A illustrates an alias data structure according to an embodimentof the present invention.

FIG. 3 is a block diagram of a server computer according to anembodiment of the present invention.

FIG. 4 is a flow diagram of a process for a method for processingpayment transaction according to an embodiment of the present invention.

FIG. 5 is a block diagram of a computer system.

FIG. 6 is a block diagram of an exemplary user device.

DETAILED DESCRIPTION

Embodiments of the present invention provide a system for validating andprocessing payment transactions between multiple parties. The systemincludes a payment processing network sever computer, data managementserver computer, a user and one or more merchants.

In order to provide a better understanding of the present disclosure, abrief review of transaction processing as it exists today is providedwith reference to FIG. 1. For ease of discussion, a transactionconducted in a physical store is described, however it should beunderstood that similar steps occur in any type of transaction,including online transactions. In a typical transaction, a user 100 mayselect goods or services to purchase at a merchant. The user may thenpay for the goods or services by presenting a transaction card, such asa debit or credit card, to the merchant. The merchant may then swipe thetransaction card through an access device 102, e.g., a Point of Sale(“POS”) terminal, to read the account number from the transaction card.

Access device 102 may then send the account number to a merchant system,where other information related to the transaction, such as purchaseamount, may be added. It should be noted that in some cases, the accessdevice and the merchant system are a single device, in which the accountnumber is read, and the purchase amount is keyed in by the merchant. Thetransaction details, such as the account number and purchase amount arethen sent from the merchant system to an acquirer system 104 to requesttransaction authorization. An acquirer is generally a bank that holds anaccount for the merchant in which funds resulting from the transactionmay eventually be deposited.

The acquirer system 104 then receives the transaction details, anddetermines a payment processing network 106 that may process thetransaction. The acquirer 104 routes the transaction to the appropriatepayment processing network 106, which in turns determines the issuer 108of the transaction card. As mentioned above, an issuer 108 may providethe user with an account that holds cash or a line of credit. Thepayment processing network 106 then routes the transaction to thecorrect issuer 108 for a transaction authorization decision. If the userhas sufficient funds in the account or sufficient available credit, theissuer 108 may authorize the transaction. The authorization response istransmitted back to the merchant, through the payment processing network106, the acquirer 104, and the access device 102. The user has thencompleted the purchase of the goods or services. At a later point intime, a settling and clearing process may occur, in which the funds areactually transferred from the user's account (or drawn on the line ofcredit) to the merchant's account at the acquirer. The settlement andclearing process occurs using the account number, wherein a request forfunds may be compared to a previous authorization, and if anauthorization exists, the funds are transferred.

Transactions may become even more complicated when a PersonalIdentification Number (“PIN”) is required. For example, in the case ofsome debit card transactions, a PIN must be entered by the user. The PINis typically entered into the access device in clear form by the user.The PIN is then encrypted using a Pin Encryption Key (PEK) in the accessdevice and is sent to a merchant system, which also knows the PEK. Themerchant system, then decrypts the PIN using the PEK, and encrypts itagain using an acquirer working key (AWK), which is a key known by themerchant and the acquirer. The acquirer then decrypts the PIN using theAWK and encrypts again using a payment processor key. The paymentprocessor in turn decrypts the PIN and encrypts using an issuer workingkey. The issuer then decrypts the PIN and determines if the PIN iscorrect.

In the traditional payment processing process described above, thetransaction is usually between a single entity that is purchasing aproduct or a service and a single entity that is providing the productor a service. There is no mechanism to validate or request moreinformation about a transaction, as part of payment processing process,before approving that transaction. For example, if a user is requestinga service from a first merchant which may be paid for by a secondmerchant contracted by the user, currently there is no mechanism bywhich the second merchant can ensure, as part of the payment processingoperation, that (a) the service is actually needed and (b) properdocumentation is available in order to authorize that service. In mostof these situation, the first merchant, the second merchant, and theuser end up exchanging information among themselves either prior toperformance of the service or after the service is rendered in order toauthorize payment for the service.

The traditional process is very cumbersome and slow. In many cases, itoften takes weeks or months before the first merchant gets paid for theservice he has provided. Also, since most of the processing for paymentauthorization involves printed paperwork and communication via regularmail, instances of lost documentation a plentiful, which further delaysthe performance of a service and/or payment for a service alreadyperformed. In addition, the traditional process is labor intensive andis costly for the merchants who generally recover pat of the costs fromthe users. Embodiments of the present invention serve to alleviate theseand many other issues with the current mechanism.

Embodiments of the current invention provide a mechanism for integratingthe payment processing infrastructure with a new infrastructure forhandling the supporting documentation and information needed to effectthe payment processing. Many advantages can be realized with the systemand methods described below. First, by automating most of thetraditional mechanisms for service and payment authorization, theproposed system can greatly enhance the speed and efficiency ofexecution. Second, the system leverages use of billions of networkconnected servers and user devices such as cell phones, mobile computingdevices, TVs', etc. to enable a user and a merchant to interact quicklyand efficiently without having to resort to traditional methods likemailing of documents. This may greatly enhance the speed of processingboth the transaction authorization and payment processing aspects of atransaction. Third, since the system uses a web-based cloud serverconfiguration to store data, the data is available for access virtuallyanywhere in the world at anytime further reducing the delay in theentire process. Fourth, the system uses WSDL, JSON, and/or RESTfulmessaging, which are universally supported by virtually all the currentnetwork enabled servers and devices. This is may greatly reduce thecost/message for communicating with the cloud server computer(s). Thesecost savings can be passed on to the merchants/users. Finally, thesystem provides a secure means of conducting transactions in which theuser need not provide his payment details to any merchant, but ratheruses only an alias to conduct transactions. The user's payment detailsare stored safely on the cloud server computer. Thus there is virtuallyno payment details exchanged between a user and a merchant, whichreduces the instances of fraud and identity theft.

FIG. 2 illustrates a functional block diagram of a system 200 accordingto an embodiment of the present invention. System 200 includes a paymentprocessing network server computer 202 that communicates with anacquirer 204 and an issuer 206. Payment processing network servercomputer 202 can be implemented, e.g., using the computer system of FIG.5. Payment processing network server computer 202 receives paymentauthorization requests and communicates with acquirer 204 and issuer 206to complete the payment transaction. In some embodiments, paymentprocessing network server computer 202 is similar to the paymentprocessing network server computer 106 of FIG. 1.

Payment processing network server computer 202 also communicates with adata store 208 that stores payment related information. In someembodiments, data store 208 may include, for a particular account,account number, payment device identifier(s) associated with theaccount, the CVV code associated with the payment device(s), accountholder information, etc. In operation, payment processing network servercomputer 202 consults with data store 208 to retrieve the informationneeded to process the payment transaction. In some embodiments, datastore 208 may be integrated into the payment processing network servercomputer 202. In other embodiments, data store 208 may be external topayment processing network server computer 202 and may comprise shareddata resources. Data store 208 may be implemented using any non-volatilestorage medium such as optical disks, HDD, or flash memory. In someembodiments, data store 208 may also include addressing and controlcircuitry for accessing the data in data store 208.

System 200 may also include a cloud server computer 210 that may beoperated by the same entity that operates payment processing networkserver computer 202. Cloud server computer 210 may be implemented, e.g.,by computer system of FIG. 5. Cloud server computer 210 may include adatabase 212, one or more application interfaces 214, storage device216, and an alias database 218.

Database 212 may have a subset of information present in data store 208.In some embodiments, database 212 may include all the information fromdata store 208. Periodically, database 212 is synchronized with datastore 208 to ensure that database 212 has the most current informationrelated to user accounts. In some embodiments, for security purposescertain information that is present in data store 208 may not be presentin database 212. Database 212 can be implemented using appropriatehardware and software components commonly available. In someembodiments, database 212 can used shared memory architecture. Sharedmemory is memory that may be simultaneously accessed by multipleprograms with intent to provide communication among them or avoidredundant copies. Shared memory is an efficient means of passing databetween programs. Depending on context, programs may run on a singleprocessor or on multiple separate processors.

Application interface 214 can include hardware and software forcommunicating with various external devices. In some embodiments,application interface may include requisite functionality for sendingand receiving WSDL messages, JavaScript Object Notation (JSON), andRESTful computing messages. WSDL (Web Services Description Language) isan XML-based language that provides a model for describing Web services.WSDL is often used in combination with SOAP and an XML Schema to provideweb services over the Internet. A client program connecting to a webservice can read the WSDL file to determine what operations areavailable on the server. Any special data types used are embedded in theWSDL file in the form of XML Schema. The client can then use SOAP toactually call one of the operations listed in the WSDL file. WSDL iswidely used for communications over a network. REST (RepresentationalState Transfer) is a style of software architecture for distributedhypermedia systems such as the World Wide Web. REST-style architecturesconsist of clients and servers. Clients initiate requests to servers;servers process requests and return appropriate responses. Requests andresponses are built around the transfer of representations of resources.A resource can be essentially any coherent and meaningful concept thatmay be addressed. A representation of a resource is typically a documentthat captures the current or intended state of a resource.

JSON is a lightweight text-based open standard designed forhuman-readable data interchange. It is derived from the JavaScriptscripting language for representing simple data structures andassociative arrays, called objects. Despite its relationship toJavaScript, it is language-independent, with parsers available for mostlanguages. The JSON format is often used for serializing andtransmitting structured data over a network connection. It is usedprimarily to transmit data between a server and web application, servingas an alternative to XML.

Storage device 216 can be implemented using a non-transitory,non-volatile storage media such as hard disks, optical disks, flashmemory, etc. In some embodiments, storage device 216 can include severalindividual storage media. In some embodiments, storage device can have acapacity in excess of 100 terabytes. In some embodiments, storage device216 may store all the supporting information for a particulartransaction.

Alias database 218 may include information about an alias. An alias maybe a representation of an individual or a business. In some embodiments,alias database 218 may include biographical information about an alias,information about devices associated with the alias, etc. A detaileddescription of an alias database is provided in the pendingcommonly-owned U.S. patent application Ser. No. 12/846,767, filed onJul. 29, 2010, the contents of which are incorporated by referenceherein in its entirety for all purposes. In some embodiments, aliasdatabase 218 may be part of database 212. FIG. 2A illustrates an exampleof data that may be store in alias database 218.

As illustrated in FIG. 2A, alias hierarchy and data structure tree 250includes a top-level alias 251 to which all other aliases and objectsare linked. As described above date illustrated in FIG. 2A may be storedin alias database 218. The alias 251 may be associated with anentity/organization, a person/individual, or a device. In someembodiments, alias 251 may be linked to other aliases within or outsidea particular tree. Alias 251 may be linked to various hierarchy groups260, 270, and 280. The hierarchy groups are used to arrange the data ina manageable form and for ease of search using standard databasequeries. Each of these hierarchy groups may represent a particular area,e.g., devices, household, individual, entity/business, etc. In FIG. 2A,the hierarchy group 260 is referred to as the business domain. Thishierarchy group relates to a business entity that may be owned oroperated by owner of the alias 251. The hierarchy group 260 may haveseveral objects linked to it. Each of the objects linked to thehierarchy group 260 in turn may have an alias associated with them. Asillustrated, the hierarchy group 260 may have an object 261 associatedwith it. The object 261 may be a network used by the business entity.The object 261 may further have objects 262 and 263 associated with it.In an embodiment, object 262 may be the internet service provider (ISP)used by the business entity and the object 263 may be the telephonecompany that provides telephone service to the business entity. Inaddition, the hierarchy group 260 may have other network type objectslinked to it. The object 263 may also have other objects 264 and 265linked to it. The object 263 may represent a financial institution,e.g., a bank, which issues a credit card 264 and where the businessentity has its checking account 265. Each of the objects 264 and 265 mayalso have an alias associated with them. Similarly, hierarchy group 260may have another financial institution 266 associated with it that mayrepresent a different bank where the business entity has an account.

Hierarchy group 270 is related to an individual domain. Hierarchy group270 includes information about an individual and his household. Forexample, hierarchy group 270 may have an object 271 that represents thespouse of the individual, an object 272 that specifies the gender of theindividual, an object 273 that represent the children of the individual,and an object 274 that represents the household of the individual. Theobject 274 may be further liked to one or more objects that represent,the address of the household, the parcel number of the household, etc.Similarly, object 271 may be further linked to other objects thatrepresent the spouse's age, gender, any other children of the spouse,etc.

Hierarchy group 280 is related to devices that may be used by a businessentity or an individual. The hierarchy group 280 may also have varioussubjects associated with it. In an embodiment, the hierarchy group mayhave objects 281, 282, 283, and 284 associated with it. The object 281may represent the vehicle owned by the individual or the businessentity. The object 282 may represent the computer owned by theindividual or the business entity. The object 283 may represent variousother electronic devices owned by the individual or the business entity.The object 284 may represent a cell phone owned by the individual or thebusiness entity. In some embodiments, the object 284 may have additionalobjects associated with it that may represent various attributes of theobject 284. For example, the object 284 may have attributes thatrepresent a phone number, serial number of the cell phone device, aserial number of a SIM card installed in the cell phone, associated withthe object 284. In some embodiments, each of the attributes may be anobject and have a unique alias associated with the object. As describedearlier, each of the objects associated with any of the hierarchy groupsmay have a unique alias associated with them.

In some embodiments, an object in one hierarchy group may also beassociated with another object in a different hierarchy group. Forexample, object 284 (cell phone) may be associated with object 264 inthe instance where the cell phone is also a payment device, e.g.,implementing contactless card technology. In some embodiments, onehierarchy group may be linked to another hierarchy group for the samealias or a different alias. For example, if a husband and wife share thesame household, the hierarchy group associated with the household may belinked to alias of the husband as well as the alias of the wife, or toany other hierarchy groups that are linked to the alias of the husbandor the wife.

Thus it can be seen that each hierarchy group can include multiplelevels of objects linked to each other within the same hierarchy group.In addition, objects in one hierarchy group can be linked to objects indifferent hierarchy groups. It is to be understood that the variousobjects and aliases illustrated in FIG. 2A are exemplary and the typeand amount of objects associated with an alias may depend on whether thealias is an individual or an entity such as a merchant described above.

Referring back to FIG. 2, system 200 may also include one or more userdevices 230 and one or more merchant server computers 232, 234. Userdevices can include mobile communication devices, televisions, PDA's,PC's, and portable computing devices. Each user device 230 may beassociated with an alias belonging to the user. In this manner, anytransaction originating or terminating at user device 230 can be trackedand properly attributed to the corresponding user. Merchant servercomputers 232, 234 can be any network enabled server computer that isassociated with a merchant. A merchant as used herein can be acorporation (e.g., Google, Facebook, etc.), a service provider (e.g., aninsurance company, auto body shop, gas station, etc.), retail outlets(e.g., Sears, Wal-Mart, etc.), a network-based information provider(e.g., search engines, social networks, etc.), or any other entity thatprovides either a product, a service, or information.

Further, while system 200 is described herein with reference toparticular blocks, it is to be understood that these blocks are definedfor convenience of description and are not intended to imply aparticular physical arrangement of component parts. Further, the blocksneed not correspond to physically distinct components. Blocks can beconfigured to perform various operations, e.g., by programming aprocessor or providing appropriate control circuitry, and various blocksmight or might not be reconfigurable depending on how the initialconfiguration is obtained.

Now, the operation of system 200 will be described below using anexample in which a user needs to get some dental work done, e.g., a rootcanal, and seeks authorization from his insurance company who mayauthorize payment for the service. It is to be understood that thescenario described below is given to explain the operation of system 200and should not be construed to limit the embodiments described herein.Consider that in FIG. 2, user device 230 is a mobile device, merchant232 is an insurance company, and merchant 234 is a doctor.

After the user associated with user device 230 visits the doctor, thedoctor proceeds to get authorization from the insurance company forperformance of the service. In order to accomplish this, the doctor(234) may send a service authorization message to cloud server computer210. Cloud server computer 210 then relays the message to the insurancecompany (232). The insurance company may need additional information inorder to authorize the service, e.g., a dental x-ray of the user. Theinsurance company may request the additional information from the doctorvia cloud server computer 210. The doctor may then upload the x-ray tocloud server computer 210 where it may be stored in storage device 216.The x-ray is then communicated to the insurance company, which mayauthorize the service. The authorization may be communicated to thedoctor along with a transaction ID for that service request. Thetransaction ID may be used to track the service when a payment requestfor that service is made.

After the doctor provides the service to the user, the doctor may submita payment request to cloud server computer 210 for the service alongwith the transaction ID for that service. Cloud server computer 210 mayrelay the payment request to the insurance company. Before the insurancecompany pays the doctor, it may want to verify that the user has indeedreceived the service. Accordingly, the insurance company may send avalidation request to user device 230 via cloud server computer 210. Theuser can validate that the service was provided by using user device230. Once the insurance company receives user validation, it can sendpayment details to cloud server computer 210. In some embodiments, cloudserver computer 210 may have payment details for the insurance companystored in database 212. At this point cloud server computer 210 may sendthe payment details to payment processing network 202 for paymentprocessing. Once the payment is successfully processed, paymentprocessing network 202 may inform cloud server computer 210 of theresults, which may be stored by cloud server computer 210. In someembodiments, the results may be communicated to the user and the doctor.

As seen from above, for a single payment transaction for the dentalservice provided to the user, there are multiple steps that occur. Inone embodiment of the present invention, cloud server computer 210handles all the supporting data and interaction that occurs prior to thepayment transaction being processed. In some embodiments, for every 1payment transaction there may be up to 9 supporting transactions thatmay occur. Since all the supporting transactions occur directly betweenend-users (user device 230, merchants 232 and 234) and cloud servercomputer 210, there is less delay and messages can be handled in anefficient manner. Cloud server computer 210 provides the individualentities with a much faster way of completing a transaction. Forexample, for the illustrative scenario described above it would havetaken weeks for the entire transaction to be completed not counting anyscheduling delays between the user and the doctor. However, with system200, the entire transaction can be completed in matter of minutes andalmost real-time. In addition, having a neutral third-party, e.g., VISA,operate the cloud server computer provides all the stake holders withassurance that their information will be properly safeguarded. Inaddition, it reduces the burden on the merchants and the users of havingto track the paperwork and manage multiple channels of communication forevery transaction.

Another example where the embodiments of the present invention may beused are in a transactions that involves a user buying gas at a gasstation. In this instance merchant 232 may be the gas station where theuser intends to buy gas for his car. Even before the user drives to thegas station, the user can communicate with cloud server computer 210using, e.g., a communication device in his car, to retrieve informationassociated with the gas station, e.g., gas price, gas availability, etc.The information associated with the gas station may be stored under thealias for the gas station in alias database 218. This information may beupdated periodically to reflect the most updated information. In anembodiment, the user device may communicate the alias of the gas stationin order to retrieve the information. In addition to the informationassociated with the gas station, cloud server computer 210 may alsogather information about the gas station from one or more informationproviders, e.g., merchant 234. Such information may include travel timebetween user's current location to the gas station including trafficconditions, an optimal travel route, reputation of the gas station interms of average wait time for fill-up, etc. All this information can besent back to the user device.

The user may then drive to the gas station. The user device maydetermine that the user is nearing the gas station, e.g., based onlocation information of the user device, and send an indication to thegas station that the user is about to arrive at the gas station. Theindication may include the user's alias information. The gas stationserver computer may use the user's alias information to requestpreauthorization from the user's payment card issuer for a potential gaspurchase. Since the user's alias information is stored in alias database218, cloud server computer can determine user's payment device andcommunicate with the issuer of the payment device to obtain thepreauthorization. When the user actually enters the gas station anddrives up to a particular pump, the user device may communicate with thegas station server via cloud server computer 210 to indicate user'slocation. In response to this information, the gas station's servercomputer can enable that pump for use.

The user may immediately start pumping gas from that pump without havingto swipe this card or present any payment device. Once the user hasfinished dispensing the gas, the gas station server may send the finalamount of purchase to cloud server 210 to be communicated to the user'sissuer. In some embodiments, the issuer may send a confirmation messageto the user's device, via cloud server computer 210, to verify that theuser indeed purchased the gas. Once the user confirms the purchase, thepayment authorization may proceed according to conventional processes.

Thus, in this exemplary scenario, the user may not have to provide hispayment details to the gas station at all. All transactions can beconducted using an alias and the gas station gets paid without everreceiving the user payment details. In addition, providing a securemeans for the user to conduct his transactions may result in encouraginguser's to use the system.

FIG. 3 is a functional block diagram of a cloud server computer 300according to an embodiment of the present invention. Cloud servercomputer (or cloud server) 300 may include a payment application 302that may be configured to interact with a payment processing network.The payment application can communicate a payment authorization requestto the payment processing network and receive messages associated withpayment processing, from the payment processing network.

Cloud server 300 may also include a data store 304 that includes a aliasdatabase 306 and alias hierarchy information 308. Alias database 306 mayinclude information about an alias. An alias can be some form of anidentifier (e.g., e-mail address) associated with an entity. The entitycan either be an individual or a company. In some embodiments, aliasdatabase 306 may include biographical information associated with analias, such as contact information, address, etc. In some embodiments,alias database 306 may also include information about a payment deviceassociated with an alias. As used herein, a payment device can be acredit card, a debit card, a smart card, an account number, etc. In someembodiments, alias database 306 may be synchronized with the databaseassociated with the payment processing network (e.g., data store 208 ofFIG. 2).

Data store 304 may also include alias hierarchy information 308. In anembodiment, alias hierarchy information may include associations betweenand alias and one or more objects (e.g., devices, real property, etc.)and between two or more aliases. For example, one of the objects may bethe cell phone associated with the alias. So, in the example above, whenthe insurance company communicates with the user to validate that theservice was provided by the doctor, it may send a message to the cloudserver computer with the alias information for the user. The cloudserver may look up the cell phone number of the user and send themessage to the cell phone. When a reply is received from the user, thecloud server computer may verify that the cell phone from where thereply originated is associated with the user. Thus, this may provide anadditional level of security and verification.

Cloud server 300 may also include data storage 310. Data storage mayinclude multiple storage devices working in synchronization to providedata storage capability. In some embodiments, data storage may have astorage capacity in excess of 100 terabytes. In some embodiments, mostof the supporting documentation associated with a particular transactionmay be stored in data storage 310. For example, in the example discussedabove, the dental x-ray and any other documentation related to theservice provided by the doctor may be stored in data storage 310. Forthis reason, it is desirable to have the storage capacity of datastorage 310 as high as possible.

Cloud server 300 may also include an application interface 312.Application interface 312 may communicate with external systems such asother network-enabled user devices and other network-enabled servercomputers that may reside at merchant locations. It is estimated thatare approximately 1 billion network-enabled user devices are inoperation currently and are projected to grow at an annual rate of 1billion/year. In order to interact with all these external systems,application interface 312 may use WSDL messaging, JSON, and/or RESTfulcomputing architecture. Use of these techniques ensures that the cost ofprocessing the large amount of transactions with the external systems iskept at a minimum. Application interface 312 can be implemented usingany suitable hardware and/or software components that are designed toutilize WSDL, JSON, and/or RESTful messaging.

Further, while cloud server computer 300 is described herein withreference to particular blocks, it is to be understood that these blocksare defined for convenience of description and are not intended to implya particular physical arrangement of component parts. Further, theblocks need not correspond to physically distinct components. Blocks canbe configured to perform various operations, e.g., by programming aprocessor or providing appropriate control circuitry, and various blocksmight or might not be reconfigurable depending on how the initialconfiguration is obtained.

FIG. 4 is a flow diagram of a process 400 for processing a transactionaccording to an embodiment of the present invention. Process 400 may beperformed, e.g., by cloud server computer 300 of FIG. 3.

Initially, the cloud server may receive a request for authorizing atransaction from a merchant (402). The cloud server may requestadditional information about the transaction from the merchant (404). Insome embodiments, the additional information may include documentation,images, audio, etc. The cloud server may communicate with the otherentity or entities involved in the transaction for validating thetransaction (406). For example, if the transaction is a request from amerchant for getting paid for an item purchased by a user, the user maybe asked to validate that he/she indeed purchased the item for whichpayment is being requested. Once the other entity validates thetransaction, the cloud server may receive payment details from the otherentity (408). In some embodiments, payment details may includeinformation about a payment device to be used for paying for the itempurchased. Once the payment details are received, the cloud server maysend the payment details to a payment processing network (410) forfurther processing. In some embodiments, prior to sending the paymentdetails, the cloud server may verify that the payment details areassociated with the other entity, e.g., by consulting the alias database306 of FIG. 3. Thereafter, the cloud server may receive results from thepayment processing operation from the payment processing network (412).The cloud server may then communicate the results to the merchant andthe user (414). In some embodiments, after completion of thetransaction, the cloud server may archive all the data related to thattransaction and associate an identifier to it for ease of retrievallater.

It should be appreciated that the specific steps illustrated in FIG. 4provide a particular method of processing a transaction according to anembodiment of the present invention. Other sequences of steps may alsobe performed according to alternative embodiments. For example,alternative embodiments of the present invention may perform the stepsoutlined above in a different order. Moreover, the individual stepsillustrated in FIG. 4 may include multiple sub-steps that may beperformed in various sequences as appropriate to the individual step.Furthermore, additional steps may be added or removed depending on theparticular applications. One of ordinary skill in the art wouldrecognize many variations, modifications, and alternatives.

FIG. 5 is a high level block diagram of a computer system that may beused to implement any of the individual components described above andmay include one or more of the subsystems or components shown in FIG. 5,which is a block diagram of a computer apparatus. The subsystems shownin FIG. 5 are interconnected via a system bus 545. Additional subsystemssuch as printer 544, keyboard 548, fixed disk 549, monitor 546, which iscoupled to display adapter 582, and others are shown. Peripherals andinput/output (I/O) devices, which couple to I/O controller 541, can beconnected to the computer system by any number of means known in theart, such as serial port 584. For example, serial port 584 or externalinterface 581 can be used to connect the computer apparatus to a widearea network such as the Internet, a mouse input device, or a scanner.The interconnection via system bus 545 allows central processor 543 tocommunicate with each subsystem and to control the execution ofinstructions from system memory 542 or fixed disk 549, as well as theexchange of information between subsystems. The system memory 542 and/orfixed disk 549 may embody a computer readable medium.

FIG. 6 is a block diagram of the basic components that may reside in anexemplary user device 614, e.g., a mobile phone, a car stereo unit, etc.according to an embodiment of the present invention. User device 614comprises a computer readable medium (CRM) 652. CRM 652 may be presentwithin a body 670, or may be detachable from it. Body 670 may be in theform a plastic substrate, housing, or other structure. CRM 652 may be amemory that stores data and may be in any suitable form including amagnetic stripe, a memory chip, etc. The memory preferably storesinformation such as financial information, transit information (e.g., asin a subway or train pass), access information (e.g., as in accessbadges), etc. Financial information may include information such as bankaccount information, bank identification number (BIN), credit or debitcard number information, account balance information, expiration date,user information such as name, date of birth, etc. Any of thisinformation may be transmitted by user device 614.

CRM 652, or memory, may further comprise any suitable code. The code maybe suitable to perform any or all of the functionality of user mobiledevice 614 as described herein. In some embodiments, CRM 614, or memory,comprises: (a) code for receiving information from the cloud servercomputer; (b) code for sending information to the cloud server computer;(c) code for sending information to the issuer computer; (d) code forsending information to the payment processing network computer; (e) codefor receiving information from the payment processing network computer;and/or (f) code for receiving information from the issuer computer.

User device 614 also comprises a camera 654. Camera 654 is operable totake pictures (i.e., acquire images), video, etc. and may include anytype of image-acquiring device known in the art. User device 614 mayalso comprise a GPS antenna 656. GPS antenna 656 is operable to receivetransmissions from GPS satellites for identifying a location of userdevice 614. GPS antenna 656 may include any type of antenna operable toreceive transmissions from GPS satellites as is known in the art.

User device 614 may also comprise other elements typically included in auser mobile communication device. For example, user device 614 may alsoinclude a processor 650 (e.g., a microprocessor) for processing thefunctions of the user device 614 and an output device 658 (e.g., adisplay) to allow a user to see phone numbers and other information andmessages, e.g., an authentication request message or a verificationmessage. User device 614 may further include input elements 660 to allowa user to input information into the device, a speaker 662 to allow theuser to hear voice communication, music, etc., and a microphone 664 toallow the user to transmit his/her voice through user device 614. Userdevice 614 may also include a cellular antenna 666 for wireless voiceand data transfer (e.g., voice and data transmission). User device 614may also include a contactless element 668, which is typicallyimplemented in the form of a semiconductor chip (or other data storageelement) with an associated wireless transfer (e.g., data transmission)element, such as an antenna. Contactless element 668 functions to permitthe exchange of data and/or control instructions between user mobiledevice 614 and an optional contactless element included in a merchantaccess device.

User device 614 may also include an accelerometer 672. Accelerometer 672is typically implemented in the form of an integrated circuit chip.Accelerometer 672 can measure the proper acceleration of user mobiledevice 614. In some embodiments, accelerometer 672 can be a multi-axisaccelerometer. The accelerometer readings can be communicated to otherexternal systems for further processing.

Although FIG. 6 shows a number of components, user device 614 accordingto embodiments of the present invention may comprise any suitablecombination or subset of such components.

Any of the software components or functions described in thisapplication, may be implemented as software code to be executed by aprocessor using any suitable computer language such as, for example,Java, C++, JSON, or Perl using, for example, conventional orobject-oriented techniques. The software code may be stored as a seriesof instructions, or commands on a computer readable medium, such as arandom access memory (RAM), a read only memory (ROM), a magnetic mediumsuch as a hard-drive or a floppy disk, or an optical medium such as aCD-ROM. Any such computer readable medium may reside on or within asingle computational apparatus, and may be present on or withindifferent computational apparatuses within a system or network.

The above description is illustrative and is not restrictive. Manyvariations of the invention will become apparent to those skilled in theart upon review of the disclosure. The scope of the invention should,therefore, be determined not with reference to the above description,but instead should be determined with reference to the pending claimsalong with their full scope or equivalents.

One or more features from any embodiment may be combined with one ormore features of any other embodiment without departing from the scopeof the invention.

A recitation of “a”, “an” or “the” is intended to mean “one or more”unless specifically indicated to the contrary.

It should be understood that the present invention as described abovecan be implemented in the form of control logic using computer softwarein a modular or integrated manner. Based on the disclosure and teachingsprovided herein, a person of ordinary skill in the art will know andappreciate other ways and/or methods to implement the present inventionusing hardware and a combination of hardware and software.

1-20. (canceled)
 21. A server computer comprising: a processor; and amemory coupled to the processor, the memory comprising instructionsexecutable by the processor to: receive, from a first computerassociated with a first entity, a request to authorize payment of atransaction corresponding to a service provided by the entity to a user;send, to the first computer, a request for additional informationassociated with the transaction corresponding to the service; inresponse to receiving the additional information, send, to a secondcomputer associated with a second entity, the additional information tovalidate the transaction using the additional information; receive, fromthe second computer, a response indicating validation of the transactionusing the additional information; send, to a device, a request tovalidate the payment request; receive, from the device, a response tothe request to validate the payment request; and send, to a computer ofa payment processing network, payment account information of the user toprocess the payment of the transaction using the payment accountinformation.
 22. The server computer of claim 21, wherein the additionalinformation includes audio, video, documentation, or a combinationthereof, and wherein the additional information is related to theservice provided to the user.
 23. The server computer of claim 21,wherein the transaction is associated with an identifier, and wherein astatus corresponding to the payment is determined using the identifier.24. The server computer of claim 21, wherein the instructions arefurther executable by the processor to: receive, from the computer ofthe payment processing network, information indicating a result ofprocessing the payment of the transaction; and send, to the firstcomputer, the received information.
 25. The server computer of claim 21,wherein the instructions are further executable by the processor to:receive, from the device, an alias identifier associated with the user;and determine the payment account information for the user using thealias identifier.
 26. The server computer of claim 21, wherein therequest to authorize the payment of the transaction includes aliasinformation associated with the user, and wherein the payment accountinformation for the user is determined using the alias identifier. 27.The server computer of claim 26, wherein the instructions are furtherexecutable by the processor to: determine information identifying thedevice based on the alias identifier.
 28. The server computer of claim26, wherein the instructions are further executable by the processor to:determine that the response to the request to validate the paymentrequest indicates that the service was provided to the user by theentity; and upon determining that the service was provided to the user,send, to the second computer, a notification that the service wasprovided to the user by the entity.
 29. A system comprising: the servercomputer of claim 21; and the second computer, wherein the secondcomputer performs operations in communication with the computer, whereinthe operations comprise: receiving, from the server computer,information indicating the request to authorize payment of thetransaction; in response to receiving the information indicating therequest to authorize payment of the transaction, sending, to the servercomputer, a verification request for additional information; receivingthe additional information to validate the transaction using theadditional information; validating the transaction based on theadditional information; and sending the response indicating validationof the transaction.
 30. A method comprising: receiving, from a firstcomputer associated with a first entity, a request to authorize paymentof a transaction corresponding to a service provided by the entity to auser; sending, to the first computer, a request for additionalinformation associated with the transaction corresponding to theservice; in response to receiving the additional information, sending,to a second computer associated with a second entity, the additionalinformation to validate the transaction using the additionalinformation; receiving, from the second computer, a response indicatingvalidation of the transaction using the additional information; sending,to a device, a request to validate the payment request; receiving, fromthe device, a response to the request to validate the payment request;and sending, to a computer of a payment processing network, paymentaccount information of the user to process the payment of thetransaction using the payment account information.
 31. The method ofclaim 30, wherein the additional information includes audio, video,documentation, or a combination thereof, and wherein the additionalinformation is related to the service provided to the user.
 32. Themethod of claim 30, wherein the transaction is associated with anidentifier, and wherein a status corresponding to the payment isdetermined using the identifier.
 33. The method of claim 30, furthercomprising: receiving, from the computer of the payment processingnetwork, information indicating a result of processing the payment ofthe transaction; and sending, to the first computer, the receivedinformation.
 34. The method of claim 30, further comprising: receiving,from the device, an alias identifier associated with the user; anddetermining the payment account information for the user using the aliasidentifier.
 35. The method of claim 30, wherein the request to authorizethe payment of the transaction includes alias information associatedwith the user, and wherein the payment account information for the useris determined using the alias identifier.
 36. The method of claim 35,further comprising: determining information identifying the device basedon the alias identifier.
 37. The method of claim 35, further comprising:determining that the response to the request to validate the paymentrequest indicates that the service was provided to the user by theentity; and upon determining that the service was provided to the user,sending, to the second computer, a notification that the service wasprovided to the user by the entity.
 38. A system comprising: aprocessor; and a memory coupled to the processor, the memory comprisinginstructions executable by the processor to: receive first locationinformation indicating that a location of a device satisfies a thresholddistance from a location of an entity; determine payment accountinformation for a user associated with the device; send, to an issuer, arequest to preauthorize payment to the entity for a good or a service,wherein the request includes the payment account information, andwherein the payment to the entity is preauthorized using the paymentaccount information; receive, from the issuer, a response indicatingthat the payment to the entity for the good or the service ispreauthorized; receive second location information indicating that thelocation of the device corresponds to the location of the entity; andsend, to a computer of the entity, a message indicating that the paymentfor the good or the service is preauthorized, wherein the good or theservice is provided to the user based on preauthorization of the paymentfor the good or the service.
 39. The system of claim 38, wherein theinstructions are further executable by the processor to: send, to thedevice, information about the entity when the location of the devicesatisfies the threshold distance.
 40. The system of claim 38, whereinthe instructions are further executable by the processor to: receive,from the computer, cost information indicating a cost of the good or theservice provided to the user; sending, to the issuer, the costinformation to authorize payment of the cost using the payment accountinformation; and sending, to the device, the cost information.